The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Today's users may have several different computing devices through which they access data and applications—for example, a desktop computer, a laptop computer, and a mobile phone. Many of these devices also store local data, such as word-processing files, presentations, email, and calendar and contact databases. For example, some mobile phones known as “smartphones” contain one or more microprocessors powerful enough to run applications such as email, web browsing, personal information management (e.g., maintaining and updating a calendar and a contact database), and many others. Examples of smartphones include the Blackberry series from Research In Motion, Ltd., and the iPhone from Apple Computer, Inc. At the same time, the user may access the same data at counterpart applications on one or more desktop or notebook computers.
The problem then arises of how to keep all of this information available in synchronized form at each of the devices through which the user accesses data and applications. For example, if the user updates a locally stored word-processing file or contact database on one device, the user may prefer that the updated information also be available on the other devices so that regardless of which device is being used, the user always accesses the most recent version of his or her data. However, for various reasons, it is often impractical or undesirable to persistently synchronize data between all of the devices a user might use.
The use of thin clients, where information is stored centrally, can simplify synchronization problems to some extent. For example, users may utilize web browsers, remote desktop clients, and/or other thin clients to access externally hosted applications that rely on centrally stored data. But thin-clients create other challenges. For example, thin-client users expect the same fast responses to their commands as they experience when data is stored and computation is performed locally. Therefore, some otherwise stateless thin-client environments improve response time by storing frequently used data on the thin client device itself. However, this approach introduces security risks when the user steps away from the thin-client device—for example, if the device contains nonvolatile storage that could be physically stolen and copied.
In all of these environments, various forms of identity verification and authentication are used to ensure that only authorized users are given access to particular applications and data. For example, a user will often “log in” by presenting credentials by which the user may be authenticated. However, many existing authentication techniques are highly vulnerable to security risks, such as password theft. Moreover, some users find it inconvenient to remember and constantly enter credentials at each of their devices (and in some cases, for each of their applications).
Various approaches to address the afore-mentioned and other issues have been described in, for example, U.S. Pat. No. 7,346,689, U.S. Pat. No. 6,654,784, U.S. Pat. No. 5,983,273, U.S. Pat. No. 5,889,942, and “Above the Clouds: A Berkeley View of Cloud Computing,” M. Armbrust et al., Technical Report No. UCB/EECS-2009-28, Electrical Engineering and Computer Sciences Department, University of California at Berkeley, Feb. 10, 2009, http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.html, the entire contents of all of which are hereinafter incorporated by reference for all purposes as if fully set forth herein. However, for a number of reasons, other approaches are desirable.